Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade @pdfme/generator to 5.0.0 #2413

Conversation

Kunalpal216
Copy link
Contributor

@Kunalpal216 Kunalpal216 commented Nov 7, 2024

What kind of change does this PR introduce?

bugfix

Issue Number:

Fixes #2317

Did you add tests for your changes?

Not required.

Summary

  1. Upgraded @pdfme/generator to 5.0.0.
  2. Added mock function for generate import from @pdfme/generator because jest couldn't map a package's internal dependency(node_modules/@pdfme/schemas/src/utils.ts) leading to test cases involving imports from @pdfme/generator to failing.

Have you read the contributing guide?

Yes

Summary by CodeRabbit

Summary by CodeRabbit

  • New Features

    • Introduced a mock generate function for testing, returning a data array as expected from the original generate utility from @pdfme/generator.
    • Added a new test case to the TableRow component to verify appropriate error handling when PDF generation fails.
  • Dependencies

    • Upgraded @pdfme/generator package to version 5.0.0, potentially introducing new features and improvements.
  • Configuration Updates

    • Updated Jest configuration to include module name mapping for improved testing capabilities.
    • Cleaned up comments in the Jest configuration for better organization.
    • Ensured the fetch API is available in the testing environment by explicitly including whatwg-fetch.

@Kunalpal216 Kunalpal216 changed the base branch from main to develop November 7, 2024 10:07
Copy link

github-actions bot commented Nov 7, 2024

Our Pull Request Approval Process

We have these basic policies to make the approval process smoother for our volunteer team.

Testing Your Code

Please make sure your code passes all tests. Our test code coverage system will fail if these conditions occur:

  1. The overall code coverage drops below the target threshold of the repository
  2. Any file in the pull request has code coverage levels below the repository threshold
  3. Merge conflicts

The process helps maintain the overall reliability of the code base and is a prerequisite for getting your PR approved. Assigned reviewers regularly review the PR queue and tend to focus on PRs that are passing.

Reviewers

Do not assign reviewers. Our Queue Monitors will review your PR and assign them.
When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

  1. comments in this PR or
  2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

  1. arbitrators of future discussions with other contributors about the validity of your changes
  2. point of contact for evaluating the validity of your work
  3. person who verifies matching issues by others that should be closed.
  4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

  1. PRs with issues not assigned to you will be closed by the reviewer
  2. Fix the first comment in the PR so that each issue listed automatically closes

Other

  1. 🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
  2. Read the CONTRIBUTING.md file make

Copy link
Contributor

coderabbitai bot commented Nov 7, 2024

Walkthrough

The changes in this pull request include updates to the jest.config.js, package.json, and the addition of a mock implementation in scripts/__mocks__/@pdfme/generator.ts. The jest.config.js file now includes a module name mapping for @pdfme/generator to a mock file, and the setupFiles configuration has been slightly reorganized. The package.json file reflects an upgrade of the @pdfme/generator package from version 4.5.2 to 5.0.0. Additionally, a new asynchronous function generate has been introduced in the mock file.

Changes

File Change Summary
jest.config.js Added module name mapping for @pdfme/generator to mock implementation; reorganized setupFiles.
package.json Updated @pdfme/generator dependency version from ^4.5.2 to ^5.0.0.
scripts/mocks/@pdfme/generator.ts Added asynchronous function generate returning a Promise<Uint8Array>.
scripts/mocks/@pdfme/generator.test.ts Introduced a new test suite for the generate function with five test cases.
src/components/CheckIn/TableRow.test.tsx Added a test case to check error handling for PDF generation failure.
src/components/CheckIn/TableRow.tsx Modified generateTag function to improve error handling and conditionally populate inputs.

Assessment against linked issues

Objective Addressed Explanation
Upgrade @pdfme/generator from 4.5.2 to 5.0.0 (#2317)

Possibly related issues

Possibly related PRs

Poem

🐇 In the land of code where rabbits play,
A generator's upgrade brightens the day.
With mocks in place, our tests will run,
Fetching data, oh what fun!
From 4.5 to 5.0, we leap with glee,
Hopping through code, as happy as can be! 🌟


📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between f45282f and 65ab361.

📒 Files selected for processing (2)
  • src/components/CheckIn/TableRow.test.tsx (2 hunks)
  • src/components/CheckIn/TableRow.tsx (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • src/components/CheckIn/TableRow.test.tsx
  • src/components/CheckIn/TableRow.tsx

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Congratulations on making your first PR! 🎊 If you haven't already, check out our Contributing Guidelines and PR Reporting Guidelines to ensure that you are following our guidelines for contributing and creating PR.

@Kunalpal216 Kunalpal216 force-pushed the upgrade-@pdfme/generator-4.5.2-to-5.0.0 branch from a6ff346 to b46bdaa Compare November 7, 2024 10:23
coderabbitai[bot]
coderabbitai bot previously approved these changes Nov 7, 2024
Copy link

codecov bot commented Nov 7, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.28%. Comparing base (cd9dd1a) to head (65ab361).
Report is 1 commits behind head on develop.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #2413   +/-   ##
========================================
  Coverage    98.28%   98.28%           
========================================
  Files          283      283           
  Lines         8221     8224    +3     
  Branches      2381     2382    +1     
========================================
+ Hits          8080     8083    +3     
  Misses         132      132           
  Partials         9        9           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (1)
scripts/__mocks__/@pdfme/generator.test.ts (1)

3-18: Test suite structure looks good, but consider adding error cases.

The test suite effectively covers the happy path with three well-structured test cases:

  1. Verifies async/Promise behavior
  2. Validates return type
  3. Checks actual values

However, since this is mocking a PDF generator, consider adding test cases for:

  • Error scenarios that the real generator might encounter
  • Edge cases with different input parameters (if the real function accepts any)

Example test cases to consider:

test('should handle error scenarios', async () => {
  // Mock error cases that might occur in the real generator
  await expect(generate(/* invalid params */)).rejects.toThrow();
});

test('should handle different input parameters', async () => {
  // Test with various input combinations if the real function accepts parameters
  const result = await generate(/* different params */);
  expect(result).toBeInstanceOf(Uint8Array);
});
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between b46bdaa and 7766328.

📒 Files selected for processing (1)
  • scripts/__mocks__/@pdfme/generator.test.ts (1 hunks)
🔇 Additional comments (2)
scripts/__mocks__/@pdfme/generator.test.ts (2)

15-16: Verify if the mock values match the real implementation's behavior.

The hardcoded values [10, 20, 30, 40, 50] seem arbitrary. We should verify if these values are sufficient for testing the actual usage of the generated PDF data in the codebase.

#!/bin/bash
# Description: Find actual usage of the generate function to understand the expected behavior
# Expected: Locate files that use the real @pdfme/generator to verify if our mock is sufficient

# Search for imports and usage of @pdfme/generator
rg -l "@pdfme/generator" --type ts --type tsx

# Search for specific uses of the generate function
ast-grep --pattern 'generate($$$)'

1-1: Verify the mock implementation exists.

Let's ensure the imported mock file exists and contains the necessary implementation.

#!/bin/bash
# Description: Verify the existence and content of the mock generator file
# Expected: Find the mock implementation of the generate function

# Check if the mock file exists and show its content
fd --type f "generator.ts" --exec cat {} \; --base-directory "scripts/__mocks__/@pdfme"

scripts/__mocks__/@pdfme/generator.test.ts Outdated Show resolved Hide resolved
@pranshugupta54 pranshugupta54 added the ignore-sensitive-files-pr The contributor has a legitimate reason for editiing protected files label Nov 7, 2024
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (2)
scripts/__mocks__/@pdfme/generator.ts (2)

11-11: Simplify object parameter

The object parameter spreading is redundant as the property names match.

-  return await pdfmeGenerate({ template: template, inputs });
+  return await pdfmeGenerate({ template, inputs });

4-12: Add input validation and error handling

The mock should validate inputs and handle errors to better mimic the real implementation.

Consider adding basic validation:

 export const generate = async ({
   template,
   inputs,
 }: {
   template: Template;
   inputs: Record<string, string>[];
 }): Promise<Uint8Array> => {
+  if (!template || !inputs) {
+    throw new Error('Template and inputs are required');
+  }
+  if (!Array.isArray(inputs)) {
+    throw new Error('Inputs must be an array');
+  }
   return await pdfmeGenerate({ template, inputs });
 };
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 7766328 and b86458a.

📒 Files selected for processing (2)
  • scripts/__mocks__/@pdfme/generator.test.ts (1 hunks)
  • scripts/__mocks__/@pdfme/generator.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • scripts/mocks/@pdfme/generator.test.ts
🔇 Additional comments (1)
scripts/__mocks__/@pdfme/generator.ts (1)

1-2: Verify the import path resolution

The import from '@pdfme/generator' might still cause Jest to fail. Let's verify if this import is being correctly mocked.

✅ Verification successful

The import path resolution is correctly configured

The import path is properly set up in Jest's configuration:

  • The moduleNameMapper in jest.config.js correctly maps @pdfme/generator to the mock implementation
  • The mock implementation exists at the correct location
  • The mock has proper test coverage
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if there are any Jest moduleNameMapper configurations for @pdfme/generator
rg -l "moduleNameMapper.*@pdfme/generator" jest.config.*

# Check for any other mock implementations of @pdfme/generator
fd -g "*generator*" -t f scripts/__mocks__

Length of output: 185


Script:

#!/bin/bash
# Let's check the content of jest.config.js to see if @pdfme/generator is properly mapped
cat jest.config.js

# Also check the mock implementation and its test
cat scripts/__mocks__/@pdfme/generator.ts
cat scripts/__mocks__/@pdfme/generator.test.ts

Length of output: 2987

scripts/__mocks__/@pdfme/generator.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (2)
scripts/__mocks__/@pdfme/generator.ts (2)

10-17: Consider enhancing mock data generation.

While the current implementation works, consider making the mock data more realistic for testing edge cases:

 export const generate = async ({
   template,
   inputs,
 }: {
   template: Template;
   inputs: Record<string, string>[];
 }): Promise<Uint8Array> => {
-  const mockLength = Math.min(template.schemas.length, inputs.length);
-  const mockReturnList = [];
-  for (let i = 1; i <= mockLength; i++) {
-    mockReturnList.push(i);
-  }
-  return Promise.resolve(new Uint8Array(mockReturnList));
+  // Generate mock PDF-like header bytes
+  const pdfHeader = [0x25, 0x50, 0x44, 0x46]; // %PDF
+  // Add some random content based on input size
+  const contentSize = Math.min(template.schemas.length, inputs.length) * 10;
+  const mockContent = Array.from(
+    { length: contentSize },
+    () => Math.floor(Math.random() * 256)
+  );
+  return Promise.resolve(new Uint8Array([...pdfHeader, ...mockContent]));
 };

This enhancement:

  1. Adds PDF magic bytes for more realistic testing
  2. Generates variable-length content based on inputs
  3. Uses random bytes to catch potential encoding issues

3-9: Consider adding error simulation capabilities.

For comprehensive testing, it would be valuable to simulate error conditions that might occur in the actual PDF generation.

+interface GenerateOptions {
+  template: Template;
+  inputs: Record<string, string>[];
+  mockError?: boolean; // For testing error handling
+}
+
 export const generate = async ({
   template,
   inputs,
+  mockError = false,
-}: {
-  template: Template;
-  inputs: Record<string, string>[];
+}: GenerateOptions): Promise<Uint8Array> => {
+  if (mockError) {
+    throw new Error('Mock PDF generation error');
+  }

This allows tests to verify error handling paths in the code that uses this generator.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between b86458a and 4cb6ba0.

📒 Files selected for processing (1)
  • scripts/__mocks__/@pdfme/generator.ts (1 hunks)
🔇 Additional comments (1)
scripts/__mocks__/@pdfme/generator.ts (1)

1-17: LGTM! The mock implementation follows best practices.

The mock correctly:

  • Maintains type safety with proper TypeScript types
  • Avoids actual package dependencies
  • Provides deterministic test data
  • Respects input constraints by using minimum length

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (1)
scripts/__mocks__/@pdfme/generator.ts (1)

10-18: Consider making the mock more deterministic and robust.

While the current implementation provides a realistic PDF-like structure, there are a few improvements to consider:

  1. The random content might make tests non-deterministic
  2. Missing null check for template.schemas

Consider this improved implementation:

 export const generate = async ({
   template,
   inputs,
 }: {
   template: Template;
   inputs: Record<string, string>[];
 }): Promise<Uint8Array> => {
   // Generate mock PDF-like header bytes
   const pdfHeader = [0x25, 0x50, 0x44, 0x46]; // %PDF
+  if (!template?.schemas) {
+    throw new Error('Invalid template: schemas is required');
+  }
   // Add some random content based on input size
   const contentSize = Math.min(template.schemas.length, inputs.length) * 10;
-  const mockContent = Array.from({ length: contentSize }, () =>
-    Math.floor(Math.random() * 256),
-  );
+  // Use deterministic content for consistent testing
+  const mockContent = Array.from({ length: contentSize }, (_, i) => i % 256);
   return Promise.resolve(new Uint8Array([...pdfHeader, ...mockContent]));
 };
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 4cb6ba0 and f383ae6.

📒 Files selected for processing (1)
  • scripts/__mocks__/@pdfme/generator.ts (1 hunks)
🔇 Additional comments (2)
scripts/__mocks__/@pdfme/generator.ts (2)

1-2: LGTM! Clean type-only import.

The import statement correctly uses type-only import for Template, maintaining clean separation between types and runtime code.


3-9: LGTM! Function signature matches the package interface.

The mock implementation correctly matches the expected interface of @pdfme/generator's generate function. Let's verify this against the actual package interface.

✅ Verification successful

Mock implementation correctly matches the package interface

The verification confirms that:

  • The mock's function signature is being used correctly in the codebase (src/components/CheckIn/TableRow.tsx)
  • The implementation follows the expected interface with proper types (Template and Record<string,string>[])
  • The mock generates valid PDF-like content for testing purposes
  • Package is properly listed in dependencies (@pdfme/generator@^5.0.0)
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that our mock matches the actual package interface
# Expected: The actual package should export a generate function with similar signature

# Search for the generate function definition in node_modules
fd -t f "generator.(js|ts|d.ts)" node_modules/@pdfme -x cat {} | rg -A 5 "export.*generate.*="

Length of output: 205


Script:

#!/bin/bash
# Let's try searching for the package.json to understand the dependencies first
fd -t f "package.json" -x cat {}

# Also search for any references to @pdfme/generator in the codebase
rg "@pdfme/generator" -A 3 -B 3

Length of output: 7748


Script:

#!/bin/bash
# Let's check the actual usage of the generate function to understand the interface
ast-grep --pattern 'generate({$$$})' 

# Also let's check the mock implementation
cat scripts/__mocks__/@pdfme/generator.ts

Length of output: 998

coderabbitai[bot]
coderabbitai bot previously approved these changes Nov 8, 2024
@Kunalpal216
Copy link
Contributor Author

Kunalpal216 commented Nov 8, 2024

@pranshugupta54 I have added tests for my additions but still the codecov test seems to not meet. Can you help ?

@pranshugupta54
Copy link
Member

@pranshugupta54 I have added tests for my additions but still the codecov test seems to not meet. Can you help ?

https://app.codecov.io/gh/PalisadoesFoundation/talawa-admin/pull/2413/indirect-changes
I think your changes will require some modifications for src/components/CheckIn/TableRow.tsx

@Kunalpal216
Copy link
Contributor Author

@pranshugupta54 Seems like src/components/CheckIn/TableRow.tsx needs some more test additions for those error cases to also get covered. I will check.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (2)
scripts/__mocks__/@pdfme/generator.ts (2)

10-12: Consider separating error cases for better testing.

While the error handling is good, combining both checks into a single condition makes it harder to test and handle specific error cases separately.

Consider separating the checks:

-  if (template.schemas.length === 0 || inputs.length === 0) {
-    throw new Error('Template or inputs cannot be empty.');
+  if (template.schemas.length === 0) {
+    throw new Error('Template schemas cannot be empty.');
+  }
+  if (inputs.length === 0) {
+    throw new Error('Inputs cannot be empty.');
   }

13-21: Consider using deterministic content for consistent testing.

While the current implementation creates valid mock data, using random content might make tests non-deterministic. Consider using a predictable pattern based on the input data.

Here's a suggested improvement:

   const pdfHeader = [0x25, 0x50, 0x44, 0x46]; // %PDF
   const contentSize = Math.min(template.schemas.length, inputs.length) * 10;
-  const mockContent = Array.from({ length: contentSize }, () =>
-    Math.floor(Math.random() * 256),
-  );
+  // Generate deterministic content based on input data
+  const mockContent = Array.from({ length: contentSize }, (_, index) => 
+    (index % 256) // Creates a repeating pattern
+  );
   return Promise.resolve(new Uint8Array([...pdfHeader, ...mockContent]));
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between f383ae6 and c0700be.

📒 Files selected for processing (2)
  • scripts/__mocks__/@pdfme/generator.test.ts (1 hunks)
  • scripts/__mocks__/@pdfme/generator.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • scripts/mocks/@pdfme/generator.test.ts
🔇 Additional comments (2)
scripts/__mocks__/@pdfme/generator.ts (2)

1-2: LGTM! Clean type import.

The import is correctly scoped to only the necessary type definition.


3-9: LGTM! Well-typed function signature.

The function signature correctly mirrors the actual @pdfme/generator API with proper TypeScript types, making it a suitable mock for testing.

coderabbitai[bot]
coderabbitai bot previously approved these changes Nov 9, 2024
@Kunalpal216
Copy link
Contributor Author

@pranshugupta54 Can you review this PR ? The test coverage issue has been resolved.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (2)
src/components/CheckIn/TableRow.tsx (1)

Line range hint 69-89: Improve test coverage for error scenarios.

The PR comments mention code coverage issues, and there are multiple istanbul ignore markers. Consider adding test cases for:

  1. Invalid name scenarios
  2. PDF generation failures
  3. Error message handling

Would you like me to help generate comprehensive test cases for these scenarios?

src/components/CheckIn/TableRow.test.tsx (1)

134-175: Consider enhancing test coverage with additional scenarios.

While the current test is good, consider these improvements for better coverage:

  1. Verify that window.open wasn't called when generation fails
  2. Add cleanup of mocks in afterEach
  3. Add tests for other failure scenarios (e.g., network errors, invalid data)

Example enhancement:

 test('If PDF generation fails, the error message should be shown', async () => {
   // ... existing test code ...

   fireEvent.click(await findByText('Download Tag'));

   expect(
     await findByText(
       'Error generating pdf: Template or inputs cannot be empty.',
     ),
   ).toBeInTheDocument();
+  expect(global.window.open).not.toHaveBeenCalled();
 });

+afterEach(() => {
+  jest.restoreAllMocks();
+});
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between c0700be and f45282f.

📒 Files selected for processing (3)
  • scripts/__mocks__/@pdfme/generator.ts (1 hunks)
  • src/components/CheckIn/TableRow.test.tsx (2 hunks)
  • src/components/CheckIn/TableRow.tsx (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • scripts/mocks/@pdfme/generator.ts
🔇 Additional comments (3)
src/components/CheckIn/TableRow.tsx (1)

69-72: Verify @pdfme/generator v5.0.0 compatibility.

Since we're upgrading to @pdfme/generator v5.0.0, we should verify if the new version handles empty inputs differently.

✅ Verification successful

Let me generate additional scripts to gather more information about how @pdfme/generator is being used in the codebase.


Let me generate additional scripts to understand how @pdfme/generator is being used in tests and if there are any breaking changes in v5.0.0.


Based on the code analysis so far, I can see that:

  1. The project is already using @pdfme/generator v5.0.0 (from package.json)
  2. The code in TableRow.tsx uses a simple generate() call with template and inputs
  3. The test files show basic usage patterns that match the current implementation
  4. No breaking changes documentation was found

Since we couldn't find any changelog or breaking changes documentation, and the code is already using v5.0.0 with a simple generate() call that follows standard PDF generation patterns, I'll generate the final response:

No compatibility issues found with @pdfme/generator v5.0.0

The code is already using v5.0.0 and follows a standard pattern for PDF generation. The empty inputs handling appears to be properly implemented with a validation check before pushing to the inputs array.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any migration guides or breaking changes documentation
fd -g "CHANGELOG.md" -g "MIGRATION.md" -g "BREAKING-CHANGES.md" -g "README.md" | xargs rg -i "5\.0\.0|breaking changes|migration"

# Search for other usages of @pdfme/generator in the codebase
rg "from '@pdfme/generator'" -A 5

Length of output: 10949


Script:

#!/bin/bash
# Search for the tagTemplate file to understand the template structure
rg -l "tagTemplate" | xargs cat

# Search for any test files related to PDF generation
fd -e test.tsx -e test.ts -e spec.tsx -e spec.ts | xargs rg "generate.*pdf"

# Search for other instances where generate is used with inputs
ast-grep --pattern 'generate($$$)'

Length of output: 101724


Script:

#!/bin/bash
# Search for package.json to see previous version
cat package.json | grep "@pdfme/generator"

# Search for any test files that use @pdfme/generator
rg -l "@pdfme/generator" | grep "test\|spec"

# Search for any mock implementations
rg -l "@pdfme/generator" | grep "mock"

# Search for any changelog or readme files in node_modules
fd -g "CHANGELOG.md" -g "README.md" node_modules/@pdfme

Length of output: 375

src/components/CheckIn/TableRow.test.tsx (2)

2-2: LGTM! Good cleanup of unused imports.

The removal of waitFor is appropriate as the tests are using findByText for async operations, which is the recommended approach.


134-175: LGTM! Good addition of error handling test.

The test effectively verifies the error message display when PDF generation fails due to empty name.

src/components/CheckIn/TableRow.tsx Outdated Show resolved Hide resolved
@pranshugupta54
Copy link
Member

LGTM

@pranshugupta54
Copy link
Member

PTAL @varshith257

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ignore-sensitive-files-pr The contributor has a legitimate reason for editiing protected files
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrade @pdfme/generator from 4.5.2 to 5.0.0
3 participants